There is an ongoing integration trend between Switched Circuit Networks (SCN) and Internet Protocol (IP) networks that, using the effective way to transport user data provided by IP networks, intends to get a less restrictive and network independent way of providing and deploying telecommunication services.
The term SCN is used in this invention to refer to a network that carries traffic (normally, telephony traffic) within channeled bearers of pre-defined sizes. Examples of SCN include Public Switched Telephone Networks (PSTN), Integrated Services Digital Networks (ISDN) or Public Land Mobile Networks (PLMNs), such as a Global System for Mobile communications (GSM) network.
The term IP network is used in this invention to refer to a network that carries traffic (normally, data traffic) within data packets. The term Data Network can also be used across this invention to refer to this kind of packet oriented network.
A goal in such integration trend is to grant inter-operation between endpoints (signaling end-points or voice/multimedia terminal devices) allocated in SCN and in IP networks.
Other goals in such integration trend is to allow allocation of nodes/functions, traditionally located in the SCN, into the IP network; thus allowing telecommunication operators to expand their networks and to speed up the deployment of new or existing services. An example could be the allocation of a Global System for Mobile communications (GSM) node, such as Home Location Register (HLR) node, into an IP network.
In this context, the transport of traditional SCN signaling protocols over IP networks was viewed as one of the main areas of concern and was addressed by the Signaling Transport (SIGTRAN) Working Group of the Internet Engineering Task Force (IETF). The intention of SIGTRAN Working Group is to define an architecture and related protocols to support transport of SCN signaling over IP in order to provide a smooth and transparent interworking between telecommunication nodes regardless their allocation: SCN or IP network.
Examples of traditional SCN signaling protocols regarded to be transported over IP networks are: Q.931; Signaling System Number 7 (SS#7) Message Transfer Part (MTP); MTP layer-3 (MTP3) user-part protocols, like Integrated Service Digital Network User Part (ISUP) or Signaling Connection Control Part (SCCP); SCCP-user protocols, like Mobile Application Part (MAP) over Transaction Capabilities Application Part (TCAP); etc.
In this scenario, two kinds of nodes were identified by SIGTRAN: nodes performing functions related to signaling conversion, named Signaling Gateways (SGs), intended to provide an interwork between nodes located in the SCN and nodes located in the IP network; and nodes performing functions related to signaling application located in the IP network (IP-located nodes), named Application Servers (ASs).
These nodes (SGs and ASs) can, depending on the approach, be seen as physical or just functional (logical) entities.
There are, however, some ambiguous definitions in SIGTRAN drafts related to the physical or logical condition related to the terms: SG and AS. So, sometimes the terms SG or AS are used to refer to the physical machine (host) where, respectively, the SG or AS functionality is implemented; and sometimes the same terms are used to refer to the logical entity that implements, respectively, the SG or AS functions, regardless if such SG and/or AS functions are carried out by means of one or more SG-hosts and AS-hosts.
Hereinafter, in this invention the terms SG (or the term SG-node) and AS (or the term AS-node) will be used to refer, to the logical entity that performs, respectively, an SG function and an AS function, regardless if such functions (SG or AS) are distributed over one or more hosts each; and the terms SG-host and AS-host will be used to refer to physical entity (physical machine or physical node) that, respectively, implements (contains) an SG function and an AS function.
Therefore, the term SG can coincide in this invention with the term SG-host if the SG is not distributed across of more than one SG-host.
In the same way, the term AS can coincide in this invention with the term AS-host if the AS is not deployed across of more than one AS-host.
According to SIGTRAN definitions, an ASP and an SGP are processes instances that implements, respectively, the functionality of an AS and of an SG. That is to say: In an SG node, a specific process instance performing the specific SG functionality is called Signaling Gateway Process (SGP). Similarly, in a AS node, a specific process instance performing the specific AS functionality is called Application Server Process (ASP).
In addition to this, and in order to avoid a single point of failure, an AS may be comprised of one or more ASPs distributed over one or more physical hosts using an active/standby or load-sharing traffic handling mode. Besides to this, and as explicitly defined in some SIGTRAN drafts, an ASP can be configured to process signaling traffic related to more than one AS (i.e.: to serve to more than one AS).
Much like the AS model, an SG may also be comprised of one or more SGPs distributed over one or more physical hosts using an active/standby or load-sharing traffic handling mode.
However, no explicit reference is given in SIGTRAN drafts about that a given SGP can be configured to process signaling traffic related to more than one SG (i.e.: to serve to more than one SG), and no reference at all is given about how such SGP configuration data can be known and handled in the ASPs.
Examples of ASPs are process of Media Gateway Controller (MGC), IP-based Service Control Point (SCP, node of Intelligent Networks), or IP-based Home Location Register (HLR, node of GSM networks).
The internet-standard defining the general architecture for SIGTRAN (RFC2719) specifies a set of 3 elements that would have to be implemented by any node involved in the transport of SCN signaling over IP networks (SG and AS), and that will have to be performed by the process(es) that implement its functionality (ASPs and SGPs).
These elements are intended to interact each other in a layered way within the same node's serving process (SGP or ASP), and each one of them is intended to communicate with its respective peer element in the interworking node's serving process (SGP or ASP) by using the services provided by the adjacent lower element in its node.
These elements (from top to bottom in the aforementioned layered structure within the same node) are: the SCN adaptation module, the Common Signaling Transport and the standard IP transport.
The first element (the SCN adaptation module) is intended to be specific for the type of SCN protocol to be transported; being the latest two elements (the Common Signaling Transport and the standard IP transport) intended to be common regardless of the SCN protocol to be transported.
For this extent, SIGTRAN Working Group has developed a set of internet-standards (although some of them are still internet-drafts) that define: a set of User Adaptation layers (UA) (one per type of SCN protocol to be transported), that implements the aforementioned SCN adaptation module; and a transport protocol, the Stream Control Transmission Protocol (SCTP, defined in internet standard RFC2960) to be used over IP (instead of other well known transport protocol such as: Transmission Control Protocol TCP or User Datagram Protocol UDP), that implements the aforementioned Common Signaling Transport, and that is able to run directly over IP.
So, the final structure of a SGP⇄ASP communication is: UA-specific-protocol over SCTP over IP (UA/SCTP/IP).
Regarding more specifically User Adaptation layers (UA), SIGTRAN is defining, among others, four internet-drafts:
SS7 MTP3-User Adaptation Layer: (“draft-ietf-sigtran-m3ua”) (M3UA)
SS7 MTP2-User Adaptation Layer (“draft-ietf-sigtran-m2ua”) (M2UA)
ISDN Q.921-User Adaptation Layer (“draft-ietf-sigtran-iua”) (IUA)
SS7 SCCP-User Adaptation Layer (“draft-ietf-sigtran-sua”) (SUA)
Each aforementioned UA draft defines its specific messages, to be exchanged between the UA layer in an SGP and the corresponding peer UA layer in an ASP, and the related procedures.
Although there is one UA draft per SCN protocol to be transported over IP-networks, some messages (and related procedures) are common for all UA layers.
These common messages belong to a set of defined management messages (named MGMT messages), and to a set of defined maintenance messages (named Application Server Process Maintenance messages, or ASPM messages).
Therefore, MGMT and ASPM sets of messages have to be supported and implemented in all nodes involved in the transport of SCN signaling (SG or AS) by the UA layers of serving processes (regardless its process type: SGP or ASP).
Additionally a set of addressing abstractions have been defined to be used in ASPM messages in order to represent and identify the signaling end-points allocated in the IP network.
These addressing abstractions identifies the range of signaling traffic that is to be handled by each AS; or in other words, the range of SCN routing parameters that are handled in the IP network by each specific AS; and are used to route incoming SCN messages received in a Signaling Gateway serving process (SGP) to the corresponding Application Server serving process (ASP) that is serving to the AS identified by the SCN routing parameter(s) in the incoming message.
So, each AS is uniquely identified in an SGP by means of an addressing abstraction that, in turn, represents a determined set of SCN routing parameters. In this context, if a specific ASP wants explicitly to specify it is serving to a specific AS (or set of ASs), such ASP includes the corresponding addressing abstraction(s) that represent to such AS(s) in the corresponding ASPM message sent to the SGP.
Examples of such addressing abstractions are Routing Context (RC) (used in ASPM messages by M3UA and SUA), and Interface Identifier (II) (used in ASPM messages by M2UA and IUA).
A Routing Context (RC) is an integer that uniquely identifies a certain set of SS#7 routing parameters (such as OPC, DPC, SIO, SSN, CIC_range, etc.) and routing parameters values.
A given set of such routing parameters and parameter values is known in SIGTRAN terminology as Routing Key (RK); and there is established a one-to-one relationship between a RC and RK.
An Interface Identifier (II) is an integer or text that identifies a physical interface at the SG for which the signaling messages are sent and received.
Regarding more specifically to the defined ASPM set of messages, such set is further divided into two sub-set of messages: Application Server Process State Maintenance messages (ASPSM messages), and Application Server Process Traffic Maintenance messages (ASPTM messages).
The set of mandatory ASPSM messages, together with its meaning, is given below:
ASPUP. Sent from the UA layer in an ASP to the peer UA layer in an SGP to indicate that it is ready to receive and to send maintenance messages.
ASPUP-ACK. Acknowledgement for ASPUP message, sent from the UA layer in the SGP to the peer UA layer in the ASP.
ASP-DOWN. Sent from the UA layer in an ASP to the peer UA layer in an SGP to indicate that it is not ready to receive nor to send maintenance messages.
ASPDOWN-ACK. Acknowledgement for ASPDOWN message, sent from the UA layer in the SGP to the peer UA layer in the ASP.
The set of ASPTM messages, together with its meaning, is given below:
ASPAC. Sent from the UA layer in an ASP to the peer UA layer in an SGP to indicate that it is active and ready to process signaling traffic for a particular AS(s), the AS(s) being identified by RC(s) parameter(s) or II(s) parameter(s) included in the message.
ASPAC-ACK. Acknowledgement for ASPAC message, sent from the UA layer in the SGP to the peer UA layer in the ASP.
ASPIA. Sent from the UA layer in an ASP to the peer UA layer in an SGP to indicate that it is not active nor ready to process signaling traffic for a particular AS(s), the AS(s) being identified by RC(s) parameter(s) or II(s) parameter(s) included in the message.
ASPIA-ACK. Acknowledgement for ASPIA message, sent from the UA layer in the SGP to the peer UA layer in the ASP.